It is known to provide resiliency, i.e. recovering traffic forwarding, in a network using segmented protection with Dual Node Interconnection (DNI) when protected domains are using linear subnetwork connection protection (SNCP) with sublayer monitoring (SNC/S).
Linear protection is a survivability mechanism when there are two possible paths that can be used for traffic forwarding: the working path where traffic is forwarded under normal conditions and the protection path where traffic is forwarded when the working path is not available or on operator's demand. The actual path used for traffic forwarding is commonly referred as the active path while the other path is commonly referred as the standby path.
The linear protection and corresponding architectures are defined in ITU-T Recommendation G.808.1 (May 2014), “Generic protection switching—Linear trail and subnetwork protection” and also in ITU-T Recommendation G.870 (October 2012), “Terms and definitions for optical transport networks”. Working, protection, active and standby paths or transport entities are respectively defined in ITU-T Recommendation G.870.
Subnetwork connection protection (SNCP) refers to a protection mechanism that protects a portion of an end-to-end connection, as shown in FIG. 11 according to ITU-T Recommendation G.808.1. The protected domain represents the portion of the end-to-end connection which is protected by the protection mechanism, as defined in ITU-T Recommendation G.870.
Selection of the active and standby paths is performed based on the status of the working and protection paths as well as some operator's commands, as defined in ITU-T Recommendation G.808.1. In normal condition—i.e. no failures or degradations and no contrary operator's commands—the working path is selected as the active path. When a failure is detected on the working path, traffic can be recovered by selecting the protection path as the active one. It is also possible for an operator to force protection switching actions, selecting the protection path as the active one.
An Automatic Protection Switching (APS) protocol is commonly used to coordinate protection switching actions, i.e. to activate the same path, between the two protection switching functions at the edges of the protected domain. APS protocol information is exchanged through in-band overhead on the protection path. There are multiple alternatives to monitor the status of the working and protection paths.
SNCP with sub-layer monitoring (SNC/S) is an architecture where the working and protection path are monitored using Operations, Administration and Maintenance (OAM) mechanisms between the edges of the protected domain.
OAM mechanisms refer to set of mechanism to monitor the status of a path. For the purpose of protection switching, OAM mechanisms are capable to detect whether there is a failure—traffic cannot be forwarded—or a degradation—traffic can be forwarded but the quality of the delivered traffic is below the agreed quality of service.
OAM mechanisms can monitor the status of the whole end-to-end connection as well as the status of a portion of the connection. In the latter case, the term tandem connection is usually indicating the portion of the connection being monitored and sublayer monitoring usually refers to the mechanism used to monitor the portion of the connection. The entity which is monitored by OAM—being either the end-to-end connection or the tandem connection—is usually called maintenance entity group (MEG). In the case of SNC/S, the MEG contains one maintenance entity so that, in the context of the present disclosure, the term maintenance entity (ME) in fact refers to MEG.
In case of SNC/S, two maintenance entities are used to monitor the status of the working and protection paths.
OAM mechanisms operate in the overhead of the specific transport technology. For TDM technologies like SDH or OTN, some bytes in the TDM/OTN frame overhead are used. For packet technologies like Ethernet or MPLS-TP, some overhead packets, defined as OAM packets, are used. The OAM packets used in Ethernet networks are defined in ITU-T Recommendation G.8013/Y.1731 (August 2015), “OAM functions and mechanisms for Ethernet-based networks”. The OpCode field in a CCM frame is used to indicate the type of OAM packet, e.g. Continuity Check Message (CCM) or Alarm Indication Signal (AIS).
Failures conditions of a maintenance entity can be detected using Continuity Check Message (CCM) OAM packets defined in ITU-T Recommendation G.8013/Y.1731, wherein in has to be noted that similar mechanisms are defined for other packet technologies like MPLS-TP. These keep-alive packets are continuously and periodically sent by one edge of the maintenance entity to the other edge of the maintenance entity. Lack of receipt of expected CCM messages is an indication that there is a failure: when three expected CCM packets in a row are lost, a Loss of Continuity defect (dLOC) is detected.
In case of SNC/S, detection of dLOC is an indication that the working or the protection path has failed and would immediately trigger protection switching actions. For example, when dLOC is detected on the working path in normal condition, protection switching actions will select the protection path as the active one.
In addition to trigger protection switching actions, detection of dLOC can also result in an alarm being sent to the operator to notify the fault condition, triggering fault location detection—i.e. identification of which is the fault root cause—and fault repair—e.g. replacement or fix of the failed component—actions.
However, reporting of an alarm when dLOC is detected is “filtered” to avoid reporting spurious or flooding the operator with secondary alarms. The process of filtering defects toward alarms is defined in ITU-T Recommendation G.7710 (February 2012), “Common equipment management function requirements”. In order to avoid spurious alarms, alarm reporting is hold-off for some time after defect detection: the standard holding time is 3.5 seconds as defined in ITU-T Recommendation G.7710.
In order to avoid flooding the operator with secondary alarms, Alarm Indication Signal (AIS) OAM packets have been defined in ITU-T Recommendation G.8013/11731. When an intermediate node detects a failure in the server layer or sub-layer termination, it generates AIS to suppress alarm reporting for dLOC since the primary alarm is the server layer or sub-layer failure detected and reported by such intermediate node.
For providing segmented protection, since SNC/S protects a portion of a connection, it is possible to use cascaded protected subnetworks as shown in FIG. 12 according to ITU-T Recommendation G.808.1.
The network shown in FIG. 12 is capable to protect against multiple faults—i.e. one fault per each protected subnetwork—but it cannot recover against any fault at the interconnection between adjacent subnetworks. The protection mechanisms in each protected domain operate independently from each other.
In order to provide resiliency against the failure at the interconnection between adjacent subnetworks, Dual Node Interconnection (DNI) architectures are defined in ITU-T Recommendation G.808.1. The points of interconnection are usually called interconnecting nodes. These architectures, with or without DNI, are usually called segmented protection.
With DNI, the protection mechanisms in each protected domain usually operate independently from each other; however some interactions between the protection mechanisms of adjacent protected subnetworks are needed to protect against interconnection node failure or isolation conditions. It is worth noting that segmented protection architectures do not require using the same protection mechanism (e.g., SNC/S) in different protected domains. It only requires that protected domains are not overlapping.
FIG. 13 shows a system according to document WD09-21, “A solution for Ethernet DNI scenario in G.mdsp (SP #4)”, Huawei, October 2015 proposing a solution for supporting DNI with SNC/S linear protection.
The system of FIG. 13 supports traffic forwarding an end-node E and a further end-node. Two protected domains (called protected subnetwork and interconnected domain) are shown, each protected domain comprising a working path and a protection path for linear protection. An interconnecting node I1 interconnects the working paths of the protected domains, while a peer interconnecting node I3 interconnects their protection paths. The interconnecting node I1 and the peer interconnecting node I3 are connected by vertical paths.
The crossed working path indicates that the working path fails, and the crossed vertical paths indicate that the vertical paths fail: in this situation, interconnecting node I1 is isolated within the protected domain (called also interconnected domain). When the interconnecting node I1 is isolated, the peer interconnecting node I3 transmits an SF(1,1) APS message to the end-node E for triggering protection switching in the end-node E. The reception of the SF(1,1) APS message by the end-node E then triggers the protection switching.
In the scenario of FIG. 13, the peer interconnecting node I3 detects the vertical link failure, and is informed about the isolation of the interconnecting node I1 through the interconnected domain.
However, there may be some cases where the peer interconnected node I3 is not able to be informed of the I1 node isolation: for example when there is a unidirectional failure detected by the interconnecting node I1 but no protocol, e.g. Distributed Resilient Network Interconnect (DRNI), is available in the interconnecting node I1 to inform the peer interconnected node I3 about this condition.
Moreover, a lack of receipt of expected CCM messages at e.g. the node E may result in false primary alarms being reported by node E to the operator. As a consequence the operator will trigger useless and expensive fault diagnostic procedures to discover that there is no fault to repair within this protected domain between node E and interconnecting node I1.
Moreover, the state of the art does not address traffic forwarding where cascading of protection switching events may happen across multiple protected domains.